There is a need for multiple isolated domains on mobile devices, such as smartphones, tablets and mobile internet devices based on Android™, Linux™, or any Unix™-based operating system (e.g. such as an iPhone™), where the applications and data that reside in a domain are isolated from security threats that may result from applications that reside outside the domain, on a website, or in another domain on the same device. Such multiple secure domains would typically be used by a single user, the device owner, to address the variable ease of access, privacy and security requirements associated with different mobile device use cases. For example, a device owner may have different ease of access, privacy and security requirements for mobile banking applications and data than they have for games applications or a device owner may desire to share certain applications on their device temporarily with a family member or friend and not share other applications and data, such as personal emails, contacts and text messages. Additionally, there is a requirement for different domains to be managed by different entities, such as the device owner or an external party, such as an institution or corporation, wherein each entity may have different security requirements for access to and use of applications and data in the domain they manage. For example, the requirements may be different across domains for the applications allowed within each domain, and the conditions under which applications can execute within a domain, each of which may need to be configurable uniquely for each domain by the entity managing the domain. There is also a need to support different user authentication mechanisms, different re-authentication timeframes, (or optionally no authentication) required to enter different domains depending on the types of apps and data contained in the domain (e.g. a device owner may not wish to enter a password to play games or to access Google™ Maps but they may desire to have a strong form of authentication to access mobile banking applications).
The current state of the art for mobile device security and domain isolation has been to use traditional personal computer (PC) and server computing security technologies, such as user accounts, hypervisors/virtualization, application wrappers and anti-virus scanning. The typical use of mobile devices is materially different, however, from these traditional environments. Mobile devices are, by nature, mobile and always with the device owner. They are connected, always on and require quick access for short duration tasks. They are shared in a way that is materially different from traditional workstation and mainframe sharing. Power consumption is also critical to mobile devices, which is one reason that power hungry virus scanning and virtualization technologies have yet to be widely used on mobile devices.
One conventional domain isolation approach is to create separate user accounts on the device, whereby each user must log-in to an account that has been configured for the user. Depending on the operating system (OS), this may force another user to be logged out. This approach supports multiple users on a single device and separates or isolates each user's application data. The same operating system is leveraged across all users and all users have the same user interface features. An installed application is accessible to all users, which is an efficient use of memory and central processing unit (CPU) resources. This also allows a user to configure their account with the look and feel they desire.
While user accounts provide data isolation and the efficiency of using the same application and OS across different user accounts, this approach suffers the following limitations. It provides all-or-nothing access to the device, without the flexibility for temporary access. “Guest” user accounts may be set up with limited access, but this does not facilitate the spontaneous sharing that is common with mobile devices (e.g. with a family member or friend). User accounts are not typically available on mobile devices, which are considered personal devices. The user must still switch between each user account, which does not reflect the way people desire to use their mobile devices. The user must log-in when switching user accounts which further inconveniences this approach, as there is no implied relationship between the first user and a second user with multi-user accounts. There is typically no inactivity timer or similar mechanism so that log-in is not always required when switching domains. The isolation between users (accounts) is at user space, or application level, and enforced by the OS. Anyone or any software with administrator or root access, including malware, can access the data of all users. Some systems do enable encryption of some user data to help mitigate this attack, but generally the user data is still highly vulnerable and any kernel level exploit or process can modify applications, processes, intercept data and access any files/objects it desires.
Moreover, conventional user accounts, which were developed at the time of mainframe computers and extended to desktops similarly, do not work well on a truly personal device such as a smartphone. Mobile devices are shared differently than mainframes or desktop computers. There is increasingly a desire from device owners and users to have an alternative to the traditional screen lock or ‘all-or-nothing’ access control mechanisms on mobile devices. For example, it is desirable for the device owner to have applications that are frequently accessed and that do not contain sensitive information in a domain that does not require user authentication; this is different from the requirements for a personal protected domain or a work protected domain. The primary goal of such an open, shared or common domain is the ease of use and quick access when the security of such applications and data are deemed not to be important by the user (e.g. weather or navigation). As such, the user does not want to enter a password or PIN each time they access such an open domain. Additionally, such an open domain could include applications that may be less trustworthy than those that the user or a domain owner may allow in their protected domain. For example, many applications on Android are known to access the contact database. Finally, while this permission must be granted during install time to enable installation of the application, many users do not check this closely or understand the implications of granting such permission.
Further conventional domain isolation approaches are now described with reference to FIGS. 1A to 1D.
As is known in the art, and as illustrated in FIG. 1A, a computing device such as a mobile device implementing an operating system may be understood as including hardware, an operating system including a kernel and middleware, and application space (or user space). The kernel manages and provides input/output (I/O) services to software applications for access to the hardware, and the middleware provides services to software applications additional to those provided by the kernel.
One conventional domain isolation approach illustrated in FIGS. 1B & 1C employs hypervisor-based virtualization or virtual machines. With virtual machines the operating system is duplicated to some degree to provide different isolated domains. There are different types of virtual machines depending on the hypervisor. A Type 1 (or bare-metal) hypervisor illustrated in FIG. 1B runs directly on the device CPU (‘bare metal’) and provides isolation of domains by supporting complete and separate deprivileged instances of the operating system for each domain. Isolation depends solely on the hypervisor. Type 2 hypervisors illustrated in FIG. 10 are another virtualization approach, wherein a second guest OS runs on top of a host OS. There are other hybrid operating-system level virtualization approaches as well.
Hypervisor-based virtualization provides isolation between domains but suffers from the following limitations. Duplication of the OS and applications means that there is significant device overhead in terms of device memory, CPU and power consumption. The high resources requirements for hypervisor solutions make the support of multiple domains impractical. Data, application sharing and inter-process communications (IPC) are ordinarily not possible, although some cross domain data sharing is proposed through special messaging services if supported by the hypervisor. Each OS is exposed to kernel layer malware that may undermine the isolation between the domains. The user must toggle back and forth between domains (e.g. to switch from a personal app to a work app), which does not reflect the manner in which people desire to use their mobile devices. The time and overhead to integrate a Type 1 or Type 2 hypervisor onto a mobile device is very high making this approach infeasible for low cost mobile devices. The performance impact of toggling between domains is high. Finally, such solutions support whatever user account and user authentication is provided by each OS, which is traditional all-or-nothing access.
A third conventional approach to domain isolation on mobile devices, illustrated in FIG. 1D, involves application-level containerization. In this case, the application containers (or domains) share the same hardware and OS, but use containerization or wrapper technology to act as a proxy between the applications in the container and the OS. This creates multiple independent domains by providing a layer of indirection so that the lower level device resources, memory and file system can be transparently mapped to higher-level resources that should be accessible only by applications in the container or domain. Containerization is relatively efficient in terms of the consumption of mobile device resources, especially compared to virtualization as there is only one version of the OS, although applications are usually duplicated inside the container and outside the container (e.g. an email app that may be used for work inside the container and for personal use outside the container). As an application level solution, container solutions have a very practical benefit in that it can be downloaded to devices already in the field (e.g. reverse compatibility).
In containerization, all of the security and all of the enforcements are wrapped around the container that contains applications. As such, anyone who downloads a contained application receives not only the application, but also all the security information associated with that application. With containerization, it remains possible for malicious individuals either: (1) to reverse engineer security policy; or (2) to execute the application in an environment such as on an emulator where information can be extracted from it.
Application-level containerization as an approach to domain isolation suffers, however, from the following limitations. From a security perspective, it is relatively easy for a hacker with some basic skills, or malware resident on the device, to intercept the calls between the container and the OS to break the isolation and capture data and personal information. Containerization is not enforced in the operating system or kernel and is exposed to malware that may be present on the device. For example, if the operating system is Linux or Android and an attacker gains root access privilege, it is relatively simple to extract domain data or other critical information from RAM (e.g. passwords used to access the domain, or cryptographic keys used to encrypt data in the domain) or for such kernel layer malware to eavesdrop on I/O drivers, such as the microphone or frame buffer. Containers isolate the applications and data that are “wrapped” by the container, but do not limit access by other applications not in the container from accessing memory, files or networks, etc. Sharing a single application image across domains is not possible and such technology does not allow the same application both inside and outside a container. As a result, a container will typically only support pre-determined applications that have been modified to the container, such as mail, messaging, browsing, contacts, calendar, etc. This does not provide the application choice that users or a corporate IT department desire. Common applications must be modified to support the container, which duplicates storage and memory on the device and increases the effort and involvement of the application developer. Often a private application store must be created specific for the container solution, which increases lock-in to a vendor solution and requires involvement by the application developer, further limiting choice. With application wrapping approaches, the executable code may need to be patched with security libraries that control how data is stored, shared and transmitted. This introduces license and copyright issues as licenses do not typically authorize the licensee to modify an application. The user must still toggle back and forth between domains or containers, which doesn't reflect the way people use their mobile devices. Finally, the domain typically has its own pre-determined user interface, which is different from the native OS user experience and cannot be customized by the device user.
A yet further approach to domain isolation is a kernel level platform security approach in the device operating system, such as Security Enhanced Linux™ (SELinux™). SELinux provides mandatory access control (MAC) for applications and users to objects and resources, such as files. Each user, or application is assigned a security label and a policy can be assigned to all labels. SELinux may be used for role-based access controls combined with a domain switching mechanism, although Android™ does not use user identifiers in such a manner. SELinux uses a special kernel module that relies on the Linux Security Module (LSM) interface in Linux to enforce isolation between processes based on the security policy. Applications can be verified against the SELinux policy before loading and all processes can be confined to pre-determined access such that one application cannot launch or access another process, directories or data if that is not allowed by the policy. With the right policy mechanisms, applications, malware and even kernel root kits can be prevented from accessing the applications and data that belong to another user or application.
While a native OS solution has many advantages from a security, performance and application isolation perspective compared to containers and compared to virtualization approaches, it suffers from the drawback that the kernel does not have sufficient visibility to the middleware level to be able to enforce domain isolation required at the middleware levels.
Moreover, kernel-level platform security as an approach to domain isolation suffers the following limitations. Such kernel module approaches do not have any user interface or the concept of domains, but typically use existing traditional user accounts, including allowing root or administrator accounts that have privileges across all domains. The kernel module used in this approach is very low in the operating system and does not have granular, application specific information to provide the type of policy control (e.g. user authentication policy for a domain) and application control (e.g. restriction of applications to certain domains) needed to meet the requirements of consumer and corporate uses of isolated domains on a mobile device. Extending SELinux type policy language and enforcement to the middleware significantly increases complexity of the solution. Such policies are typically static and not updated. There have been projects to provide remote policy updates for SELinux, but policies apply to the whole device and are not unique for each domain. Inter-Process Communications (IPC), on Android for example, are difficult to monitor, because the permission checks and caller/callee checks are performed in the Android Middleware and the kernel does not have access to enough information to monitor and control IPC between domains. Finally, there is typically not granular enough control of the user and application access to define inter-domain data sharing, which raises issues with data leakage, which is not acceptable for certain types of data. While this may be acceptable for some shared applications (e.g. camera and picture gallery), there is a higher degree granularity needed for documents and document reader applications (e.g. pdf viewer) that is not possible with a kernel level solution.
Another conventional approach to providing security is encrypted filesystems, such as a cryptographic stacked filesystem. For example, the eCryptFS filesystem (http://ecryptfs.org) is a POSIX-compliant enterprise cryptographic stacked filesystem for Linux. Encrypted filesystems are not a suitable means, however, for providing multiple domains.
It is, therefore, desirable to provide means for creating multiple domains on mobile devices where the applications and data that reside in a domain are isolated from security threats that may result from applications that reside outside the domain on a website or in another domain on the same device, and which mitigates one or more disadvantages of each of the conventional approaches described above, provides advantages over such conventional approaches, or provides an alternative to such convention approaches.